Pasar de ProxySQL 2.7 a 3.0 suena a salto de versión mayor, de esos que dan pereza meter en producción sin motivo. La empresa francesa PmaControl, que desarrolla herramientas de monitorización para MySQL y MariaDB, acaba de publicar un dato concreto que merece la pena mirar con lupa: en sus pruebas, la misma comprobación de caché de ProxySQL pasó de 8,1 a 2,0 milisegundos de media al actualizar de la serie 2.7 a la 3.0. Un 75% menos de tiempo, o lo que es lo mismo, algo más de cuatro veces más rápido.
El titular es llamativo, y hay que leerlo con cuidado: no mide el rendimiento de ProxySQL enrutando tráfico de una aplicación real, sino una consulta muy concreta contra su interfaz de administración. Vamos a ver qué se probó exactamente, qué hay detrás del cambio de versión y cómo encaja con lo que sabemos de ProxySQL en otros benchmarks.
Qué es ProxySQL, por si no lo conoces
ProxySQL es un proxy que se coloca entre la aplicación y los servidores MySQL o MariaDB (desde hace poco también PostgreSQL). Reparte las consultas entre varios backends, cachea resultados, reescribe queries sobre la marcha con reglas y expone todo eso a través de una interfaz de administración que se consulta con SQL normal y corriente, como si fuera una base de datos más. Por debajo, esa interfaz de administración usa SQLite.
El cambio real no es solo el número de versión
El salto de 2.x a 3.0 coincide con algo más de fondo: en marzo de 2026, el equipo de ProxySQL anunció una nueva estrategia de publicación en tres niveles, con tres versiones lanzadas el mismo día (3.0.6, 3.1.6 y 4.0.6). La razón que dan es que su comunidad se ha dividido en dos perfiles con necesidades opuestas: quien necesita estabilidad «aburrida» para producción crítica, y quien quiere ir probando funciones nuevas de observabilidad e IA generativa cuanto antes.
- Stable (3.0.x): el nivel pensado para producción, centrado en endurecer el protocolo y corregir errores.
- Innovative (3.1.x): incorpora todo lo de Stable y añade funciones que aún se están rodando, como la base de datos de series temporales embebida o el observador de tráfico Fast Forward.
- AI/MCP (4.0.x): el terreno experimental, con integraciones para agentes de IA y el protocolo MCP.
Las tres ramas comparten el mismo núcleo y avanzan juntas: cada versión del tier superior incluye todo lo del tier inferior. Así que 3.0 no es solo "la siguiente versión de 2.7", es el primer peldaño de un esquema de mantenimiento distinto.
Qué ha cambiado técnicamente entre 2.7 y 3.0
Al margen del benchmark, hay cambios de fondo documentados en las notas de las versiones 3.0.x que explican por qué la serie 3.0 no es un simple parche de la 2.7:
- Soporte de PostgreSQL como protocolo Extended Query desde la 3.0.3, el protocolo que usan de verdad las aplicaciones que trabajan con prepared statements contra Postgres, no solo el protocolo simple.
- Un tokenizador de queries específico para PostgreSQL en la 3.0.4, que agrupa correctamente consultas parecidas al generar sus digests, algo que antes se apoyaba en heurísticas pensadas para MySQL.
- El propio changelog de la 3.0.4 dice literalmente que «las rutas críticas de replicación y de prepared statements son más rápidas», aunque sin publicar cifras concretas de esa mejora.
- Seguimiento de variables de sesión de MySQL y sincronización de clúster para PostgreSQL en la 3.0.8, más una tabla nueva para configurar SSL por servidor backend.
- Timeout de query por hostgroup en la 3.0.10: antes, si querías un timeout distinto al global para un grupo de servidores concreto, tenías que escribir una regla de query aparte; ahora es un parámetro directo.
- La 3.0.10 corrige además un fallo de seguridad real, catalogado como GHSA-fvch-fpgq-pwfx: el descompresor zlib de ProxySQL no comprobaba que el número de bytes producidos coincidiera con el que declaraba el paquete recibido.
Ese último punto por sí solo ya es motivo suficiente para planificar la actualización en cualquier instancia expuesta, con independencia de lo que diga cualquier benchmark de rendimiento.
El benchmark de PmaControl, con detalle
PmaControl no midió el rendimiento general de ProxySQL. Midió el tiempo de una función muy concreta de su propia herramienta, QueryCacheEffectiveness::run(), que lanza dos consultas de solo lectura contra la interfaz de administración de ProxySQL para comprobar si la caché de queries está funcionando:
-- Primera consulta: reglas de caché activas y sus contadores de coincidencia
SELECT r.rule_id, r.cache_ttl, r.digest,
r.match_digest, r.match_pattern,
COALESCE(h.hits, 0) AS hits
FROM runtime_mysql_query_rules r
LEFT JOIN stats_mysql_query_rules h
ON h.rule_id = r.rule_id
WHERE r.active = 1 AND r.cache_ttl > 0
ORDER BY r.rule_id;
-- Segunda consulta: contadores de caché y tamaño configurado
SELECT Variable_Name AS name, Variable_Value AS value
FROM stats_mysql_global
WHERE Variable_Name IN (
'Query_Cache_count_GET', 'Query_Cache_count_GET_OK',
'Query_Cache_count_SET', 'Query_Cache_Memory_bytes',
'Query_Cache_Entries', 'Query_Cache_Purged'
)
UNION ALL
SELECT variable_name, variable_value
FROM global_variables
WHERE variable_name = 'mysql-query_cache_size_MB';
El motivo de la prueba es curioso: PmaControl tenía un bug propio. Una regla de query válida con identificador negativo (rule_id=-1) y un TTL de 5.000 ms hacía que la comprobación se cortara después de la primera lectura, y devolvía «estadísticas no disponibles» sin llegar nunca a ejecutar la segunda consulta. Al corregir ese bug y ejecutar siempre las dos lecturas completas, aprovecharon para comparar el tiempo de esa comprobación ya corregida entre ProxySQL 2.7.3 y 3.0.5.
La metodología: una máquina virtual compartida con Ubuntu 24.04.4, 2 vCPU, 4 GiB de RAM y PHP 8.4.26, conexión por loopback contra compilaciones nativas de 2.7.3-12-g50b7f85 y 3.0.5-60-g7e9e009. Por cada versión, 15 lotes de 10 auditorías cronometradas tras 3 llamadas de calentamiento, 150 auditorías completas por versión.
Métrica | ProxySQL 2.7.3 | ProxySQL 3.0.5 | Reducción |
Media, ms/auditoría | 8,112 | 2,015 | 75,16 % |
Mediana de medias por lote | 7,896 | 2,054 | 73,99 % |
Media máxima de un lote | 11,914 | 2,919 | 75,50 % |
Pico de memoria PHP | 4 MiB | 4 MiB | sin cambios |
Un detalle que dice mucho a favor de la seriedad del benchmark: PmaControl publica los datos crudos (300 duraciones individuales en JSON), un script en Python para recalcular la tabla desde cero y el hash SHA-256 del código que ejecutó cada prueba. Se puede reproducir el cálculo sin fiarse de la palabra de nadie, algo que no abunda en este tipo de publicaciones de empresa.
Lo que este benchmark no demuestra
El propio autor, Aurélien Lequoy, es explícito con las limitaciones, y conviene repetirlas porque es fácil que se pierdan al compartir solo el titular del "4 veces más rápido":
- Se ejecutó en una VM compartida, no en hardware dedicado, con todo lo que eso implica de ruido de otros procesos.
- El orden de las versiones no se alternó: en cada proceso se probó siempre primero la 2.7.3 y después la 3.0.5, lo que deja abierta la puerta a efectos de caché de sistema u otros sesgos de orden.
- No se calcula ningún intervalo de confianza sobre los resultados.
- Los conjuntos de resultados son pequeños (una fila y siete filas), muy lejos de una tabla con millones de registros.
- No certifica el throughput de queries de aplicación, ni la latencia de enrutamiento del tráfico real, ni el comportamiento bajo alta concurrencia.
Dicho de otra forma: el dato es real y está bien documentado, pero lo que mide es la velocidad de consultar el estado interno de ProxySQL desde una herramienta de monitorización, no la velocidad de ProxySQL sirviendo tráfico de producción. Para una herramienta como PmaControl, que necesita sondear ese estado con frecuencia sin generar carga extra, es una mejora real y relevante. Para decidir si tu aplicación va a ir más rápida con 3.0, no dice gran cosa por sí solo.
Cómo encaja con el histórico de rendimiento de ProxySQL
Este no es el primer benchmark que ProxySQL tiene a su favor, aunque los más citados son ya antiguos y conviene situarlos en su fecha. En sus propias pruebas frente a MariaDB MaxScale, ProxySQL ya destacaba por aguantar mejor la concurrencia alta: con 8 hilos de trabajo y 256 conexiones llegaba a duplicar el throughput de MaxScale en modo Read-Write, y con Fast-Forward superaba a MaxScale en modo solo lectura hasta en un 85% en algunos escenarios.
Percona llegó a una conclusión parecida en una comparativa publicada en 2016 con ProxySQL 1.2.0b frente a MaxScale 1.4.1: con 100 hilos, el tiempo máximo de respuesta de MaxScale llegaba a 13.795 ms frente a los 22,7 ms de ProxySQL; con 300 conexiones, 120.252 ms frente a 97,9 ms. Son versiones de hace una década y no sirven para hablar del ProxySQL de hoy, pero explican por qué la fama de ProxySQL como proxy que escala bien bajo carga viene de lejos, y por qué cualquier mejora adicional en su rama 3.0 se recibe con interés.
La conclusión práctica
Si usas una herramienta de monitorización que interroga constantemente la interfaz de administración de ProxySQL (reglas de caché, estadísticas, variables), el salto a 3.0 puede notarse de verdad, según este dato. Si lo que te preocupa es el enrutamiento de las consultas de tu aplicación bajo carga real, este benchmark no es el que responde a esa pregunta: hace falta tu propia prueba de carga, con tu esquema, tus queries y tu concurrencia, antes de mover producción.
Lo que sí es una razón de peso para actualizar sin esperar a hacer benchmarks propios es la corrección de seguridad de la 3.0.10 en el descompresor zlib. Y, si administras varias instancias, merece la pena decidir de antemano en qué tier quieres vivir: Stable si buscas lo de siempre con menos sobresaltos, Innovative si te interesan las funciones de observabilidad que aún se están rodando.
Imagen: Pexels / Brett Sayles